Utilizing Removable Virtual Volumes For Sharing Data On A Storage Area Network

ABSTRACT

The present disclosure provides data sharing through virtual removable volumes. A virtual volume of a SAN (storage area network) is presented to clients as a virtual removable volume. A controlling application controls access of clients connected to the SAN to the virtual removable volume. The controlling application allows only one client at a time to access the virtual removable volume. The controlling application allows a first client to mount the virtual removable volume as a removable volume. The controlling application then causes the first client to unmount the virtual removable volume and allows a second client to mount the virtual removable volume as a removable volume. In this way, the first client and second client are able to share data via the virtual removable volume without causing corruption of data and without requiring a shared file system or physical transfer of removable media.

CROSS REFERENCE

This application is a Continuation of U.S. Ser. No. 13/333,554, filed onDec. 21, 2011, which is a Continuation of U.S. Ser. No. 12/070,443,filed Feb. 19, 2008, now U.S. Pat. No. 8,099,497, issued Jan. 17, 2012,the entire disclosures of which are incorporated herein by reference inits entirety.

FIELD OF THE INVENTION

This invention relates generally to storage area networks (SAN), andparticularly to SAN volumes.

BACKGROUND OF THE INVENTION

A storage area network (SAN) is an architecture for attaching remotecomputer storage devices (e.g. disk arrays, tape libraries, and opticaljukeboxes) to servers in such a way as to appear to clients that thedevices are locally attached. Storage devices are presented to clientsby SANs as virtual volumes. Many organizations utilize SANs to connectstorage devices such as RAIDs (redundant array of independent disks) toservers. Many SAN utilize the SCSI (small computer system interface)protocol for communication between servers and storage devices.

A shared disk file system, or cluster file system, is an enterprisestorage file system which can be shared (concurrently accessed forreading and writing) by multiple clients. A shared disk file system istypically utilized to share one or more virtual volumes of a SAN betweenmultiple clients.

Removable media refers to storage media which can be removed from itsreader device. Examples of removable media include floppy disks, CDs(including rewritable CDs), DVDs (including rewritable DVDs), tapecartridges, USB (universal serial bus) drives, removable hard drives,and memory cards.

SUMMARY OF THE INVENTION

Accordingly, the present disclosure provides data sharing throughvirtual removable volumes: A virtual volume of a SAN may be presented toclients as a virtual removable volume. A controlling application maycontrol access of clients connected to the SAN to the virtual removablevolume. The controlling application may only allow one client at a timeto access the virtual removable volume. The controlling application mayallow a first client to mount the virtual removable volume as aremovable volume and utilize the virtual removable volume. Thecontrolling application may then cause the first client to unmount thevirtual removable volume and allow a second client to mount the virtualremovable volume as a removable volume and utilize the virtual removablevolume. In this way, the first client and second client may share datavia the virtual removable volume without causing corruption of data andwithout requiring a shared file system or physical transfer of removablemedia.

The controlling application may comprise a distributed applicationexecuting on a number of clients and the distributed applicationexecuting on each of the clients may communicate with the distributedapplication executing on the other clients. If the controllingapplication comprises a distributed application, the controllingapplication may cause the clients to mount or unmount the virtualremovable volume utilizing IOCTL (input/output control). Alternatively,the controlling application may comprise a centralized applicationexecuting on a centralized application server and may communicate withthe number of clients. If the controlling application comprises acentralized application, the controlling application may cause theclients to mount or unmount the virtual removable volume utilizing theload eject (loej) bit in a START STOP UNIT SCSI (small computer systeminterface) command.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the invention as claimed. The accompanyingdrawings, which are incorporated in and constitute a part of thespecification, illustrate an embodiment of the invention and togetherwith the general description, serve to explain the principles of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

The numerous advantages of the present invention may be betterunderstood by those skilled in the art by reference to the accompanyingfigures in which:

FIG. 1 is a flowchart 100 illustrating sharing of data via a virtualremovable volume, in accordance with an exemplary embodiment of thepresent invention;

FIG. 2 is a block diagram illustrating a system for sharing of data viaa virtual removable volume, in accordance with an exemplary embodimentof the present invention;

FIG. 3 is a block diagram illustrating a system for sharing of data viaa virtual removable volume, in accordance with an alternative embodimentof the present invention; and

FIG. 4 is a flow chart of a method for sharing of data via a virtualremovable volume, in accordance with an exemplary embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the presently preferredembodiments of the invention, examples of which are illustrated in theaccompanying drawings.

SANs (storage area network) typically present access to a virtual volumefor reading and writing to a single client. This is due to the fact thatif multiple SAN clients were to attempt concurrent access to the samevirtual volume, data may rapidly become corrupt. Absent mechanisms toprevent two or more clients from performing a modification of the samepart of the file system of the virtual volume at the same time,corruption of data may occur. Conventional file locking can protectfiles against concurrent access, but offers no protection of the filesystem itself.

Typically, when a virtual volume of a SAN needs to be utilized by two ormore clients, a shared disk file system, or cluster file system, must beutilized. A shared file system provides currency control for the filesystem of the virtual volume. Each client accessing the shared filesystem is provided with a consistent and serializable view of the filesystem, thus avoiding corruption and unintended data loss. Shared filesystems may distribute file system information across all the members ina cluster or may utilize a centralized file system information server.However, a shared file system may be complex and expensive, particularlywhen clients do not access the virtual drive simultaneously. In such acase a shared file system is cumbersome because the clients may utilizethe virtual drive one at a time.

Removable media (including, but not limited to, floppy disks, CDs(including rewritable CDs), DVDs (including rewritable DVDs), tapecartridges, USB (universal serial bus) drives, removable hard drives,and memory cards) may be utilized to share data between computingdevices which need non-simultaneous access to the data. However, toshare the data the removable media must be mounted on a first computingdevice, utilized by the first computing device, physically removed fromthe first computing device, transferred to another computing device, andmounted on the second computing device. This process of physicaltransfer is cumbersome and requires manual intervention. Further, theremovable media is vulnerable during transfer and loss of sensitive datamay result.

A virtual volume of a SAN may be presented to clients as a virtualremovable volume. A controlling application may control access ofclients connected to the SAN to the virtual removable volume. Thecontrolling application may only allow one client at a time to accessthe virtual removable volume. The controlling application may allow afirst client to mount the virtual removable volume as a removable volumeand utilize the virtual removable volume. The controlling applicationmay then cause the first client to unmount the virtual removable volumeand allow a second client to mount the virtual removable volume as aremovable volume and utilize the virtual removable volume. When thefirst client and/or the second client receive an input/output requestfor the virtual removable volume and the virtual removable volume is notmounted, the first client and/or the second client may send anotification to the originator of the input/output request that thevirtual removable volume is unavailable. In this way, the first clientand second client may share data via the virtual removable volumewithout causing corruption of data and without requiring a shared filesystem or physical transfer of removable media.

FIG. 1 is a flowchart 100 illustrating sharing of data via a virtualremovable volume, in accordance with an exemplary embodiment of thepresent invention. From a start 101, the controlling applicationdetermines 102 whether to mount the virtual removable volume on a firstcomputing device or a second computing device. The controllingapplication may determine to mount the virtual volume on the firstcomputing device or the second computing device based on one or morereceived requests for the virtual removable volume. The receivedrequests for the virtual volume may originate from the first computingdevice and/or the second computing device. Alternatively, thecontrolling application may determine to mount the virtual volume on thefirst computing device or the second computing device based on a timeschedule detailing when the first computing device is to have access tothe removable virtual volume and/or when the second computing device isto have access to the removable virtual volume. Alternatively, thecontrolling application may determine to mount the virtual volume on thefirst computing device or the second computing device based on a timelimit where the first computing device or the second computing devicemay be allowed to access the removable virtual volume for the durationof the time limit before the other computing device is allowed to accessthe removable virtual volume. If the controlling application determinesto mount the virtual removable drive on the first computing device, thecontrolling application may determine 103 whether the virtual removabledrive is already mounted on the second computing device. If the virtualremovable drive is already mounted on the second computing device, thecontrolling application may send an eject command to the secondcomputing device 105 and the second computing device may unmount thevirtual removable drive in response to receiving the eject command. Thecontrolling application may then send a load command to the firstcomputing device 104 and the first computing device may mount thevirtual removable drive in response to receiving the load command. Ifthe virtual removable drive is not already mounted on the secondcomputing device, the controlling application may send a load command tothe first computing device 104 and the first computing device may mountthe virtual removable drive in response to receiving the load command.The controlling application then determines 102 whether to mount thevirtual removable volume on the first computing device or the secondcomputing device.

Alternatively, if the controlling application determines to mount thevirtual removable drive on the second computing device, the controllingapplication may determine 106 whether the virtual removable drive isalready mounted on the first computing device. If the virtual removabledrive is already mounted on the first computing device, the controllingapplication may send an eject command to the first computing device 108and the first computing device may unmount the virtual removable drivein response to receiving the eject command. The controlling applicationmay then send a load command to the second computing device 107 and thesecond computing device may mount the virtual removable drive inresponse to receiving the load command. If the virtual removable driveis not already mounted on the first computing device, the controllingapplication send a load command to the second computing device 107 andthe second computing device may mount the virtual removable drive inresponse to receiving the load command. The controlling application thendetermines 102 whether to mount the virtual removable volume on thefirst computing device or the second computing device.

FIG. 2 illustrates a system 200 for sharing of data via a virtualremovable volume, in accordance with an exemplary embodiment of thepresent invention. The system 200 includes a SAN 201 with a virtualvolume 204, a first computing device 202 communicably connected to theSAN 201, and a second computing device 203 communicably coupled to theSAN 201. In this embodiment the controlling application may comprise adistributed application executing on the first computing device 202 andthe second computing device 203 and the distributed applicationexecuting on each of the first computing device 202 and the secondcomputing device 203 may communicate with the distributed applicationexecuting on the other computing device. The distributed applicationexecuting on each of the first computing device 202 and the secondcomputing device 203 may communicate with the distributed applicationexecuting on the other computing device via the SAN 201 and/or the firstcomputing device 202 and the second computing device 203 may becommunicably connected and the distributed application executing on eachof the first computing device 202 and the second computing device 203may communicate with the distributed application executing on the othercomputing device directly. A distributed application is an applicationmade up of distinct components executing in separate runtimeenvironments connected via a network. When the controlling applicationcomprises a distributed application executing on the first computingdevice 202 and the second computing device 203, the load and ejectcommands the controlling application may send to the first computingdevice 202 and the second computing device 203 may be implementedutilizing IOCTL (input/output control). IOCTL may comprise part of auser-to-kernel interface of the first computing device and/or the secondcomputing device. IOCTL may be typically employed to allow userspacecode to communicate with hardware devices or kernel components. Thecontrolling application may comprise computer-executable instructionsembodied in a tangible media (including, but not limited to, a mainmemory, a cache memory, a hard drive, a flash memory, a floppy disk, aCD, a DVD, and/or a memory card) of the first computing device and/orthe second computing device and the first computing device and/or thesecond computing device may execute the computer-executableinstructions.

FIG. 3 illustrates a system 300 for sharing of data via a virtualremovable volume, in accordance with an alternative embodiment of thepresent invention. The system 300 includes a SAN 301 with a virtualvolume 304, a first computing device 302 communicably connected to theSAN 301, a second computing device 303 communicably coupled to the SAN301, and a third computing device 305 communicably coupled to the SAN301. In this embodiment the controlling application may comprise acentralized application executing on the third computing device 305 andmay communicate with the first computing device 302 and the secondcomputing device 303. The centralized application executing on the thirdcomputing device 305 may communicate with the first computing device 302and the second computing device 303 via the SAN 301 and/or the thirdcomputing device 305 may be communicably connected to the firstcomputing device 302 and the second computing device 303 and thecentralized application executing on the third computing device 305 maycommunicate with the first computing device 302 and the second computingdevice 303 directly. When the controlling application comprises acentralized application executing on the third computing device 305, theload and eject commands the controlling application may send to thefirst computing device 302 and the second computing device 303 may beimplemented utilizing the load eject (loej) bit in a START STOP UNITSCSI (small computer system interlace) command as specified in SCSI-3Block commands. The START STOP UNIT SCSI command is used to control themotor of a rotary device such as a SCSI disk drive and/or to load oreject removable media. The controlling application may comprisecomputer-executable instructions embodied in a tangible media(including, but not limited to, a main memory, a cache memory, a harddrive, a flash memory, a floppy disk, a CD, a DVD, and/or a memory card)of the third computing device and the third computing may execute thecomputer-executable instructions.

Referring now to FIG. 4, a method 400 for sharing of data via a virtualremovable volume, in accordance with an exemplary embodiment of thepresent invention, is illustrated. In step 401, determine to load avirtual volume of a storage area network (SAN) on a first computingdevice. Determining to load the virtual volume of the SAN on the firstcomputing device may utilize a controlling application. Thedetermination to load the virtual volume of the SAN on the firstcomputing device may be based on one or more received requests for thevirtual removable volume. The received requests for the virtual volumemay originate from the first computing device. Alternatively, thedetermination to load the virtual volume of the SAN on the firstcomputing device may be based on a time schedule detailing when thefirst computing device is to have access to the removable virtualvolume. Alternatively, the determination to load the virtual volume ofthe SAN on the first computing device may be based on the expiration ofa time limit. In step 402, send a first load command to the firstcomputing device, Sending the first load command to the first computingdevice may utilize the controlling application. Sending the first loadcommand to the first computing device may cause the first computingdevice to mount the virtual volume in response to receiving the firstload command. The first load command may be implemented utilizing IOCTLif the controlling application comprises a distributed application. Thefirst load command may be implemented utilizing the load eject (loej)bit in a START STOP UNIT SCSI command if the controlling applicationcomprises a centralized application,. In step 403, determine to load thevirtual volume of a SAN on a second computing device. Determining toload the virtual volume of the SAN on the second computing device mayutilize the controlling application. The determination to load thevirtual volume of the SAN on the second computing device may be based onone or more received requests for the virtual removable volume. Thereceived requests for the virtual volume may originate from the secondcomputing device. Alternatively, the determination to load the virtualvolume of the SAN on the second computing device may be based on a timeschedule detailing when the second computing device is to have access tothe removable virtual volume. Alternatively, the determination to loadthe virtual volume of the SAN on the second computing device may bebased on a time limit where the first computing device or the secondcomputing device may be allowed to access the removable virtual volumefor the duration of the time limit before the other computing device isallowed to access the removable virtual volume. In step 404, send aneject command to the first computing device. Sending the eject commandto the first computing device may utilize the controlling application.Sending the eject command to the first computing device may cause thefirst computing device to unmount the virtual volume in response toreceiving the eject command. The eject command may be implementedutilizing IOCTL if the controlling application comprises a distributedapplication. The eject command may be implemented utilizing the loadeject (loej) bit in a START STOP UNIT SCSI command if the controllingapplication comprises a centralized application. In step 405, send asecond load command to the second computing device. Sending the secondload command to the second computing device may utilize the controllingapplication. Sending the second load command to the second computingdevice may cause the second computing device to mount the virtual volumein response to receiving the second load command. The second loadcommand may be implemented utilizing IOCTL if the controllingapplication comprises a distributed application. The second load commandmay be implemented utilizing the load eject (loej) bit in a START STOPUNIT SCSI command if the controlling application comprises a centralizedapplication.

Although the above has been illustrated and described in the context oftwo computing devices, it should be understood that the any number ofcomputing devices may be utilized, such as three or twenty, withoutdeparting from the scope of the present disclosure.

The present disclosure may present virtual volume of a SAN to clients asa virtual removable volume. The present disclosure may utilize acontrolling application to control access of clients connected to theSAN to the virtual removable volume. The controlling application mayonly allow one client at a time to access the virtual removable volume.The controlling application may allow a first client to mount thevirtual removable volume as a removable volume and utilize the virtualremovable volume. The controlling application may then cause the firstclient to unmount the virtual removable volume and allow a second clientto mount the virtual removable volume as a removable volume and utilizethe virtual removable volume. in this way, the present disclosure allowsthe first client and second client to share data via the virtualremovable volume without causing corruption of data and withoutrequiring a shared file system or physical transfer of removable media.

It is understood that the specific order or hierarchy of steps in theprocesses disclosed is an example of exemplary approaches. Based upondesign preferences, it is understood that the specific order orhierarchy of steps in the processes may be rearranged while remainingwithin the scope of the present invention. The accompanying methodclaims present elements of the various steps in a sample order, and arenot meant to be limited to the specific order or hierarchy presented.

It is believed that the present invention and many of its attendantadvantages will be understood by the foregoing description. It is alsobelieved that it will be apparent that various changes may be made inthe form, construction and arrangement of the components thereof withoutdeparting from the scope and spirit of the invention or withoutsacrificing all of its material advantages. The form herein beforedescribed being merely an explanatory embodiment thereof, it is theintention of the following claims to encompass and include such changes.

What is claimed is:
 1. A method performed by a controlling applicationin a storage network, the storage network including a first computingdevice, a second computing device, and a virtual volume, wherein onlyone of the first computing device and second computing device mounts thevirtual volume at a time, the method comprising: controlling the firstcomputing device to mount the virtual volume; receiving a request by thesecond computing device to access the virtual volume; in response to thereceived request, sending a command to the first computing device,causing the first computing device to unmount the virtual volume; andcontrolling the second computing device to mount the virtual volumeafter the virtual volume is unmounted from the first computing device,in which the first computing device and the second computing deviceshare data by transferring the data from the first computing device tothe virtual volume so that the second computing device can access thedata, the second computing device being able read and write the data. 2.The method of claim 1, wherein the controlling application comprises: acentral controlling application executing on a third computing devicecommunicatively coupled to the first computing device and the secondcomputing device.
 3. The method of claim 2, wherein the command includesa load eject (loej) bit in an START STOP UNIT SCSI (Small ComputerSystem Interface) command.
 4. The method of claim 1, wherein thecontrolling application comprises: a distributed controlling applicationcomprising at least a first distinct component executing on the firstcomputing device and a second distinct component executing on the secondcomputing device and wherein the first computing device is communicablyconnected to the second computing device and the first distinctcomponent communicates with the second distinct component.
 5. The methodof claim 4, wherein controlling the second computing device to mount thevirtual volume comprises: sending a IOCTL (Input/Output Control) commandto the second computing device.
 6. The method of claim 1, whereincontrolling the first computing device to mount the virtual volumecomprises: sending a load command to a driver of the first computingdevice, causing the driver of the first computing device to mount thevirtual volume onto the first computing device.
 7. The method of claim1, wherein sending a command to the first computing device, causing thefirst computing device to unmount the virtual volume comprises: sendingan eject command to a driver of the first computing device, causing thedriver of the first computing device to unmount the virtual volume fromthe first computing device.
 8. The method of claim 1, whereincontrolling the second computing device to mount the virtual volumecomprises: sending a second load command to a driver of the secondcomputing device, causing the driver of the second computing device tomount the virtual volume onto the second computing device.
 9. The methodof claim 1, further comprising: receiving an input/output request forthe virtual volume at the first computing device when the virtual volumeis unmounted from the first computing device; and informing anoriginator of the input/output request that the virtual volume isunavailable.
 10. Computer-executable instructions, embodied in anon-transitory tangible medium, for performing a method when executed bya processor, the method performed in a storage network, the storagenetwork including a first computing device, a second computing device,and a virtual volume, wherein only one of the first computing device andsecond computing device mounts the virtual volume at a time, the methodcomprising: sending a first command to the first computing device tomount the virtual volume; receiving a request by the second computingdevice to access the virtual volume; in response to the receivedrequest, controlling the first computing device to unmount the virtualvolume; and sending a second command to the second computing device tomount the virtual volume after the virtual volume is unmounted from thefirst computing device, in which the first computing device and thesecond computing device share data by transferring the data from thefirst computing device to the virtual volume so that the secondcomputing device can access the data, the second computing device beingable read and write the data.
 11. The computer-executable instructionsof claim 10, wherein the method is performed by a controllingapplication that comprises: a central controlling application executingon a third computing device communicatively coupled to the firstcomputing device and the second computing device.
 12. Thecomputer-executable instructions of claim 11, wherein controlling thefirst computing device to unmount the virtual volume comprises sending aload eject (loej) bit in an START STOP UNIT SCSI (Small Computer SystemInterface) command to the first computing device.
 13. Thecomputer-executable instructions of claim 10, wherein the method isperformed by a controlling application that comprises: a distributedcontrolling application including at least a first distinct componentexecuting on the first computing device and a second distinct componentexecuting on the second computing device and wherein the first computingdevice is communicably connected to the second computing device and thefirst distinct component communicates with the second distinctcomponent.
 14. The computer-executable instructions of claim 13, whereinthe first and second commands are implemented by IOCTL (Input/OutputControl).
 15. The computer-executable instructions of claim 10, whereinsending a first command to the first computing device comprises: sendinga load command to a driver of the first computing device, causing thedriver of the first computing device to mount the virtual volume ontothe first computing device.
 16. The computer-executable instructions ofclaim 10, controlling the first computing device to unmount the virtualvolume comprises: sending an eject command to a driver of the firstcomputing device, causing the driver of the first computing device tounmount the virtual volume from the first computing device, utilizingthe controlling application.
 17. The computer-executable instructions ofclaim 10, wherein sending a second command to the second computingdevice comprises: sending a load command to a driver of the secondcomputing device, causing the driver of the second computing device tomount the virtual volume onto the second computing device.
 18. Thecomputer-executable instructions of claim 10, wherein the method furthercomprises: receiving an input/output request for the virtual volume atthe first computing device when the virtual volume is unmounted from thefirst computing device; and informing an originator of the input/outputrequest that the virtual volume is unavailable.
 19. A computer systemcomprising: a first computing device communicatively coupled in astorage network with a second computing device and a third computingdevice, the first computing device including memory storinginstructions, which when executed, cause the first computing device toperform the following actions: controlling the second computing deviceto mount the virtual volume; receiving a request by the third computingdevice to access the virtual volume; in response to the receivedrequest, controlling the second computing device to unmount the virtualvolume; and controlling the third computing device to mount the virtualvolume after the virtual volume is unmounted from the second computingdevice, in which the second computing device and the third computingdevice share data by transferring the data from the second computingdevice to the virtual volume so that the third computing device canaccess the data, the third computing device being able read and writethe data.
 20. The computer system of claim 19, wherein the firstcomputing device executes a central controlling application to controlmounting and unmounting the virtual volume.